It has a single call site. And also remove all the `debug!` calls that
clutter up the code. The end result is much easier to read, with
`try_mark_previous_green` now recursively calling itself directly,
instead of indirectly via `try_mark_parent_green`.

… it is locked for reading

This code is only needed by an obscure `-Z` flag, so pulling it out of the main
path makes the normal logic easier to follow.

Fixes https://www.github.com/rust-lang/rust/issues/154392

…=fmease

Tweak incorrect assoc item note

Fix rust-lang#142797
r? @fmease

…alueFormat-i686, r=marcoieni

Fix LegacyKeyValueFormat report from docker build: i686

Part of rust-lang#152305

r? @marcoieni

interpreter error reporting: remove arguments that are always the same

This `report` function is called twice and both callers use the same `span` and `get_span_and_frames`... so let's just fix those arguments inside the function, no need to be more generic than this.

Replace `truncate(0)` with `clear()`

…en, r=oli-obk

Inline and remove `DepGraphData::try_mark_parent_green`.

It has a single call site. And also remove all the `debug!` calls that clutter up the code. The end result is much easier to read, with `try_mark_previous_green` now recursively calling itself directly, instead of indirectly via `try_mark_parent_green`.

r? @oli-obk

…=joboet

Prevent no_threads RwLock's write() impl from setting mode to -1 when it is locked for reading

In my time updating the docs to `std::sync::RwLock` and adding a test verifying that max reader count is reachable in rust-lang#153555, I noticed that the no_threads RwLock's `write()` implementation always sets the `mode` to `-1` (denoting writer locked) even though it could be reader locked. I feel like that's logically incorrect and that it should only be setting the `mode` to `-1` when we know that the mode is unlocked (`0`); `write()` should mirror the code that `read()` and `try_read()` has with `try_write()`.

For reference on read/try_read and write/try_write current implementations:
```rust
    #[inline]
    pub fn read(&self) {
        let m = self.mode.get();
        if m >= 0 {
            self.mode.set(m + 1);
        } else {
            rtabort!("rwlock locked for writing");
        }
    }

    #[inline]
    pub fn try_read(&self) -> bool {
        let m = self.mode.get();
        if m >= 0 {
            self.mode.set(m + 1);
            true
        } else {
            false
        }
    }

    #[inline]
    pub fn write(&self) {
        if self.mode.replace(-1) != 0 { // <-- This behavior logically does something different than what `try_write` does
            rtabort!("rwlock locked for reading")
        }
    }

    #[inline]
    pub fn try_write(&self) -> bool {
        if self.mode.get() == 0 {
            self.mode.set(-1);
            true
        } else {
            false
        }
    }
```

r? @jhpratt

…me-secret-of-success-in-testing-normalize, r=fmease

Normalize rustc path prefix when testing `-Z track-diagnostics`

Fixes rust-lang#154392

Use the normal arg-parsing machinery for `-Zassert-incr-state`

The flag parser for `-Zassert-incr-state` currently extracts an `Option<String>`, and then performs an ad-hoc parsing step slightly later. From looking at rust-lang#90386, I can't see any reason why it doesn't just use the normal flag-parsing machinery.

A second commit also extracts the underlying implementation to a separate helper function, so that it isn't cluttering up the main control flow.

I found this while working on larger cleanups to incremental-file loading.

…pat, r=Kivooeo

Emit a pre-expansion feature gate warning for `box`'ed struct field patterns

While the following code triggers a feature gate *warning*:

```rs
fn f() {
    #[cfg(false)]
    let box x; //~ WARN box pattern syntax is experimental
}
```

the code below does not (on stable & main):

```rs
fn f() {
    #[cfg(false)]
    let Struct { box x };
}
```

This is an oversight as both are part of the unstable feature `box_patterns` (that isn't properly gated pre expansion for historical reasons). Of course, both forms lead to a feature gate error *post expansion*.

This is a bug fix and doesn't need any input from T-compiler or T-lang. For context, emitting warnings in these cases is legitimized by [MCP 535](https://github.com/rust-lang/compiler-team/issues/535)[^1].

Part of rust-lang#154045.

[^1]: In case you're wondering why the MCP talks about a *lint* even though the feature gate warnings as seen today don't reference any lint by name, read rust-lang#154045 (comment).

…-obk

EnumSizeOpt: use Allocation::write_scalar instead of manual endianess logic

The first commits makes the test actually show the bytes of the newly generated allocation, so we'd notice if something goes wrong.

The 2nd commit replaces manual endianess handling with use of proper `Allocation` methods.

r? @oli-obk

…r=oli-obk

interpret: ensure that untupled arguments are actually tuples

Something seems very wrong if they are not. ;)